home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ietf / 92mar / ftpext-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.4 KB  |  122 lines
  1. This is only a rough draft - Megan 04/20/92
  2.  
  3. Minutes of the FTP Extensions BOF at IETF 23
  4. Jordan Brown, 16 April 1992
  5.  
  6. The mail traffic and discussion at the meeting basically involved people's
  7. wish lists for the protocol.  Topics included:
  8.  
  9.         . passing "auxiliary" information about files - dates, etc.
  10.         . automatic authentication
  11.         . encryption
  12.         . on-the-fly compression
  13.         . checkpointing/restart
  14.         . language selection for messages
  15.         . message digest calculation
  16.         . atomic store (FTP your nuclear waste to...)
  17.         . various protocol cleanups/clarifications
  18.         . more sophisticated conversions - character set, app, etc.
  19.         . should write both a spec and an "implementor's guide"
  20.         . time conversion issues - time zones, DST, etc.
  21.  
  22. There was consensus that a Working Group should be formed, and when a
  23. deafening silence resulted from a call for volunteers to chair it, I
  24. agreed to.  (Volunteers are still solicited!)  Russ Hobby offered to
  25. host the mailing list and archives.  The initial mailing list is the
  26. BOF attendees.
  27.  
  28. Mailing list:      ietf-ftpext@ucdavis.edu
  29. Requests:          ietf-ftpext-request@ucdavis.edu
  30. Archive:           ucdavis.edu: /archive/ftpext-archive
  31.  
  32. No date was set for the next meeting.
  33.  
  34. Detailed comments:
  35.  
  36. . passing "auxiliary" information about files - dates, etc.
  37.         The goal would be to build an extensible mechanism allowing a
  38.         client and server to pass "auxiliary" information about files.
  39.         Extended versions of LIST, RETR, STOR, etc would pass this
  40.         information, and a new command would be added to change it.
  41.         Matching client and server should be able to pass all of the
  42.         information their native system supports; non-matching pairs
  43.         would pass as much as they have in common.  A major open issue
  44.         is whether the data should be passed in binary as type-length-value
  45.         or in some printable-ASCII form.
  46. . automatic authentication
  47.         There are two basic ways in which authentication data might be
  48.         passed at present - using FTP commands or, relaxing the spec
  49.         a bit, using TELNET options on the control connection.  It was
  50.         suggested that authentication and encryption are big complex
  51.         issues on their own, and that they be split off from the rest
  52.         of the items on the wish lists.
  53. . encryption
  54.         There was interest in encryption of both the data and the
  55.         control channel.  Encryption is tightly tied to authentication,
  56.         and the two should probably be treated as a unit.
  57. . on-the-fly compression
  58.         Some servers already implement on-the-fly compression triggered
  59.         by variations in the file name.  The patent status of LZW is an
  60.         issue which needs to be researched and resolved.
  61. . checkpointing/restart
  62.         Some attendees sought official blessing for Rick Adams' stream
  63.         mode restart capability (present in some BSD clients and
  64.         servers).  It was noted that it is unclear whether or not this
  65.         mechanism truly works for NVT-ASCII mode transfers.  It was clear
  66.         that the restart marker for this mechanism should be measured in
  67.         data-connection octets.  Implementing such a restart mechanism
  68.         might be tricky on systems where the local<->network translation
  69.         is not strictly invertible.
  70. . language selection for messages
  71.         Seems pretty self-explanatory; obviously no system will support
  72.         all languages, but support for multiple languages seems
  73.         reasonable.  This issue will come up in other contexts (SMTP,
  74.         etc); perhaps there should be a more global framework.
  75. . message digest calculation
  76.         The goal is to allow automatic mirroring of archives without
  77.         having to transfer all of the data.
  78. . atomic store
  79.         The disposition of the file resulting from a failing STOR is
  80.         unspecified; a new command would require that the file be
  81.         deleted if the transfer was not completed successfully.
  82. . various protocol cleanups/clarifications
  83.         RFC 1127 lists several response code cleanups and
  84.         clarifications.  Experience with newer servers which make more
  85.         extensive use of multiline responses indicates that not all
  86.         clients can handle them.  The syntax for multiline responses
  87.         is apparently not clear enough; there has been confusion.
  88.         Note that FTP multiline responses are more liberal than SMTP
  89.         multiline responses.
  90. . more sophisticated conversions - character set, app, etc.
  91.         An extended version of NVT-ASCII mode would allow for
  92.         transmission of non-USASCII characters; a mechanism would be
  93.         needed to specify what character set is in use and what
  94.         translations should be applied.  This issue has already been
  95.         addressed in Kermit and the lessons learned there should be
  96.         applied.  A still more sophisticated mechanism to automatically
  97.         do application-level transformation (eg Microsoft Word to TeX)
  98.         would certainly be useful, but is obviously a very complex
  99.         topic.
  100. . should write both a spec and an "implementor's guide"
  101.         It was mentioned that FTP has numerous common pitfalls, and an
  102.         informational document pointing out these pitfalls and suggesting
  103.         implementation schemes would help implementors and improve
  104.         interoperability.
  105. . time conversion issues - time zones, DST, etc.
  106.         Once FTP is passing around time information (file modification
  107.         times, mostly), it becomes important to know what the times
  108.         really mean, so that meaningful comparisons and conversions can
  109.         be done.  One obvious answer is to require that all times be
  110.         expressed in GMT, but that is awkward for the large (and ever-
  111.         increasing) number of machines which don't know what time zone
  112.         they're in.  One scheme for dealing with this would be to
  113.         provide a command which gives the server's current time with
  114.         respect to whatever TZ it finds convenient; the client can
  115.         compare this with its current time to determine the offset to be
  116.         applied to other times.  This requires very loosely synchronized
  117.         clocks - less than 15 minutes difference.  It's not clear
  118.         whether DST confuses this issue - a file stored under DST and
  119.         later retrieved under ST might have its times mistranslated.
  120.         (Portable computers make time issues a nightmare.)
  121.  
  122.